idnits 2.17.1 draft-ietf-tuba-addr-assign-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 241 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1994) is 11000 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 1561 (ref. '1') == Outdated reference: A later version (-03) exists of draft-ietf-catnip-base-02 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TUBA Working Group Dave Katz 2 INTERNET-DRAFT cisco Systems 3 March 1994 5 Dynamic Assignment of OSI NSAP Addresses in the Internet 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the I-D abstract listing contained in each Internet 21 Draft directory to learn the current status of this or any Internet 22 Draft. 24 Abstract 26 There are currently two mechanisms defined for dynamic assignment of 27 OSI NSAP addresses. This memo specifies a single mechanism for hosts 28 to use that maximizes flexibility while allowing administrative 29 control, and requires no configuration on the host. 31 The method described in the memo is intended to be implemented 32 universally in all end systems supporting CLNP, both for TUBA [1] and 33 pure OSI systems. This document will be submitted to ISO for 34 consideration as a standard. Additionally, the method described 35 could also be used in CATNIP [2] networks. 37 1. Passive Address Assignment 39 The first method of dynamic address assignment, which I shall call 40 the "passive" method, was first implemented by DEC Phase V end 41 systems. In this scheme, when a host is first initialized, it 42 passively listens on its local subnetwork for ES-IS [3] Intermediate 43 System Hello (ISH) packets. When it hears one, it performs surgery 44 on the network address it finds therein, replacing the system ID of 45 the router with a globally unique value found in a ROM (typically the 46 MAC address of one of its interfaces), and claims the resulting 47 address as its own. It then emits End System Hello packets, 48 notifying routers of its choice. If no ISH is heard, the host will 49 choose an address consisting of AFI 49 ("local") followed by its 50 unique value. 52 This method has the advantage that it is allows the host to be 53 completely autonomous, requiring no additional protocol to be 54 defined. It has at least a couple of weaknesses, however. First of 55 all, it allows no administrative control over the choice of address 56 (or whether to allow one to be assigned at all!)--some network 57 administrators do not take kindly to machines popping up on their 58 networks willy-nilly and becoming full-fledged, globally reachable 59 network entities. Secondly, if there are multiple area addresses in 60 use in the area, or if the LAN is a level-2 circuit, the host will 61 hear multiple area addresses, and is faced with some ambiguity over 62 what its address should be. 64 2. Active Address Assignment 66 In response to the need for address assignment, and in recognition of 67 some of the problems with the passive approach, ISO defined Addendum 68 1 to the ES-IS protocol [4], providing a mechanism for address 69 assignment. 71 Unlike the passive method, the ISO standard method uses a 72 request/response model, putting the decision over address assignment 73 in the hands of the address assignment entity, rather than the host. 74 In this scheme, the host multicasts a Request Address (RA) packet 75 (consisting of only a basic ES-IS packet header), and the address 76 assignor replies with a unicast Assign Address (AA) packet containing 77 the network address that the host should use. 79 A proposed extension to this protocol [5] gives the host the ability 80 to suggest a system ID to the assignor, allowing the host to provide 81 some other bit of a priori information to the algorithm (such as an 82 IP address in a dual-stacked TUBA host). 84 If the host does not receive a response to its Request Address packet 85 after a reasonable number of attempts, the standard specifies that 86 the host should assign itself an address consisting of AFI 49 87 ("local") followed by one of its subnetwork addresses, which allows 88 the host to communicate on its local subnetwork only. 90 3. The Dilemma 92 Each of these approaches has its advantages. Probably the biggest 93 advantage to the passive approach is that it can work today without 94 any help from the routers (especially since the active approach is 95 not widely implemented as yet). To make the active approach 96 mandatory would mean that some end systems could not do automatic 97 address assignment, a situation that we want to avoid. However, the 98 passive approach does not lend itself well to administrative control 99 or to more clever approaches to address assignment. 101 4. The Address Assignment Process 103 The goal is to have a *single* mechanism specified for implementation 104 in the hosts, such that it could be implemented today in a way that 105 provides the advantages of both methods without requiring any manual 106 configuration. The mechanism works as follows: 108 The host first sends ES-IS Request Address packets. It may 109 optionally add the Suggested System ID option defined in [5] if it 110 wishes to influence the system ID portion of the assigned address. 111 If an Assign Address packet is received, the host uses the address 112 carried therein according to the ES-IS standard. When the holding 113 time on the assigned address is in danger of expiring, the host shall 114 perform the address assignment process again. 116 If no Assign Address packet is received after a number of tries, the 117 host falls back into the passive approach. It builds its own network 118 address by taking the address of a router (as announced in an ES-IS 119 ISH packet) and putting one of its subnetwork addresses, or some 120 other value known to be unique within the IS-IS area, into the system 121 ID portion of the address. The host shall choose a holding time not 122 to exceed 65535 seconds for this assignment, and shall perform the 123 address assignment process again should it choose to continue to 124 communicate after the holding time expires. The host shall not 125 continue to use the self-assigned address after the holding time 126 expires. 128 If no ISH packets are received within a reasonable amount of time, 129 the host shall construct a network address by using AFI 49 and 130 concatenating its subnetwork address or other value known to be 131 unique on all attached subnetworks. The host shall choose a holding 132 time and adhere to the rules specified in the previous paragraph. 134 If an ISH is heard after the host has assigned itself a local 135 address, and the host desires connectivity beyond the local 136 subnetwork, the host may choose to perform the address assignment 137 process at any time. 139 Note that the host may choose to invoke the address assignment 140 process at any time; in particular, to avoid loss of connectivity, 141 it is recommended that the address assignment process be performed 142 prior to the expiration of the holding timer. 144 5. Administrative Issues 146 It may be desirable to control the access of newly-attached hosts. 147 In particular, for administrative purposes, it may be desirable to 148 not allow global internetwork access to and from a host for some 149 period of time (for instance, when a new system is first connected). 150 Note that simply ignoring the Request Address packets will not have 151 the desired effect, since the host will perform the passive 152 assignment method and simply give itself a global network address. 154 This can be avoided by explicitly assigning an address of only local 155 scope (i.e., starting with AFI 49) in response to the Request Address 156 packet. This will effectively limit the host to communications on 157 the local subnetwork (and particularly cautious network 158 administrators could filter out any traffic sourced from an address 159 under AFI 49 in order to eliminate outgoing traffic as well). 161 It should be noted, of course, that this process is not secure in any 162 real sense, but will avoid problems when well-behaved host software 163 is in use. 165 References 167 [1] Piscitello, D., "Use of ISO CLNP in TUBA Environments," RFC 1561, 168 1993. 170 [2] Ullmann, R., "CATNIP--Common Architecture for Next-generation 171 Internet Protocol," draft-ietf-catnip-base-02.txt, 1994. 173 [3] ISO, "End system to Intermediate system routeing exchange 174 protocol for use in conjunction with the Protocol for providing the 175 connectionless-mode network service (ISO 8473)," ISO 9542:1988. 177 [4] ISO, "Dynamic Discovery of OSI NSAP Addresses by End Systems," 178 ISO 9542 Amendment 1, 1992. 180 [5] Katz, D., "Suggested System ID Option for the ES-IS Protocol," 181 Internet Draft, 1994. 183 Author's Address 185 Dave Katz 186 cisco Systems 187 1525 O'Brien Dr. 188 Menlo Park, CA 94025 189 USA 191 Phone: +1-415-688-8284 192 Fax: +1-415-688-8282 193 Email: dkatz@cisco.com