idnits 2.17.00 (12 Aug 2021) /tmp/idnits38743/draft-marcinik-ipatm-auto-arp-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 (2022-05-21) 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) 2022 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 (November 22, 1995) is 9677 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) ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carl Marcinik 2 Expires May 16, 1996 FORE Systems,Inc. 3 Fong Ching Liaw 4 Ipsilon Networks,Inc. 5 November 22, 1995 7 ATMARP Client Autoconfiguration 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This memo describes an extension to RFC 1577 [1] that allows an 32 ATMARP client to automatically locate its ATMARP server. This 33 procedure is facilitated through the use of ATM anycast addressing 34 [2]. ATMARP clients use a LIS-specific anycast address to locate 35 their LIS-designated ATMARP Server. Both an ATMARP client and an 36 ATMARP server algorithmically determine their LIS-specific anycast 37 address upon restart. The use of this procedure will significantly 38 relieve the administrative burden currently required to (re)configure 39 a Classical IP network. 41 This procedure requires that an IP address and subnet mask be made 42 available (e.g., through manual configuration) before 43 autoconfiguration can be initiated for a given ATMARP client or 44 server. In addition, this procedure requires an ATMARP client or 45 server to support the capability to detect a change to its IP address 46 and/or subnet mask during operation. The autoconfiguration procedure 47 requires no changes to the packet formats specified for ATMARP and 48 InATMARP in [1]. This procedure is not applicable to PVCs. 50 While autoconfiguration is the preferred mode of operation for an 51 ATMARP client, all clients must support manual configuration of their 52 ATMARP server address. Interoperability between ATMARP servers and 53 clients supporting this autoconfiguration procedure and those that do 54 not is subject to the following constraints. An ATMARP server 55 utilizing this autoconfiguration procedure must be able to service 56 all clients in the LIS whether they support manual configuration or 57 autoconfiguration. Therefore, this procedure requires that an ATMARP 58 server accept calls to either the LIS-specific anycast address or its 59 individual ATM address. For the case in which a LIS is serviced by an 60 ATMARP server not supporting this procedure, clients are restricted 61 to using manual configuration only. 63 1. ATMARP Client Autconfiguration Procedures 65 In addition to the operational requirements specified for an ATMARP 66 client in [1], the client, upon restart, must determine the "ATMARP 67 Client Autoconfiguration" anycast address to use for the LIS to which 68 it belongs. The client accomplishes this by retrieving its IP address 69 and subnet mask and forming a subnet number. The resulting subnet 70 number is then embedded within the designated anycast address (see 71 ATMARP Client Autoconfiguration Anycast Address Format) and is used 72 as the ATMARP Request Address (atm$arp-req) by the client. The client 73 then contacts the ATMARP server to register its ATMARP information as 74 outlined in [1] using the LIS-specific anycast address to setup the 75 call. 77 If, during operation in the autoconfiguration mode, a client detects 78 that its subnet mask or IP address has changed, it must release its 79 connection (if one exists) to the ATMARP server. If the client's 80 subnet mask has changed, or if its IP address has changed in such a 81 way as to affect its LIS membership, it should discard all ARP table 82 entries associated with the affected LIS and determine the (new) 83 LIS-specific anycast address as previously outlined. Finally, 84 (whether or not LIS membership) has changed, the client must re- 85 register with its LIS-designated ATMARP server. 87 2. ATMARP Server Autconfiguration Procedures 89 In addition to the operational requirements specified for an ATMARP 90 server in [1], the server, upon restart, must determine the "ATMARP 91 Client Autoconfiguration" anycast address to use for the LIS it will 92 serve. This is accomplished as outlined above for an ATMARP client. 93 Upon determining the LIS-specific anycast address, the server 94 registers it with the network using the ILMI address registration 95 procedure [2] (see also ILMI Address Registration below). The 96 registration of the anycast address is in addition to (not instead 97 of) the registration of the server's individual ATM address. Upon 98 successful registration of the anycast address with the network, an 99 ATMARP server accepts calls/connections to either the LIS-specific 100 anycast address or its individual ATM address as outlined in [1]. 102 When a call/connection is established using a LIS-specific anycast 103 address (or an individual ATM address for that matter), an ATMARP 104 server must use its individual ATM address as the "hardware" address 105 in any (In)ATMARP packets it exchanges with a client. The VC created 106 as a result of a call/connection established using the LIS-specific 107 anycast address may be shared and thus may also be used for non- 108 address resolution traffic. 110 If, during operation in the autconfiguration mode, a server detects 111 that its subnet mask has changed, or that its IP address has changed 112 in such a way as to affect its LIS membership, it must perform the 113 following actions. First, it must deregister the appropriate anycast 114 address from the network. The server must then release all client 115 connections that correspond to the affected LIS and discard their 116 associated ARP table entries. The ATMARP server then determines the 117 new LIS-specific anycast address to be used and registers this 118 address with the network using the ILMI address registration 119 procedure. Upon successful completion of address registration, the 120 server accepts calls/connections to either the (new) LIS-specific 121 anycast address or its individual ATM address. 123 3. ILMI Address Registration 125 If the autoconfiguration procedure is supported by an ATMARP server, 126 the ILMI address registration procedure must be used to register both 127 its individual ATM address and its LIS-specific anycast address with 128 the network as described in [2]. The occurrence of any of the events 129 listed below, following successful registration of these addresses, 130 will cause the addresses to be automatically de-registered: 132 o A coldStart Trap received from the network-side UME 134 o Detection of a "UNI Down" condition by the user-side UME 136 o A coldStart Trap sent by the user-side UME to the network-side 137 UME 139 In response to any of these events, the server must re-register the 140 LIS-specific anycast address with the network in addition to 141 performing ILMI address registration for the server's individual ATM 142 address. Once the server's LIS-specific anycast address and 143 individual ATM address have been successfully registered, the server 144 again accepts calls/connections to either address. 146 4. ATMARP Client Autoconfiguration Anycast Address Format 148 The format of the LIS-specific anycast address identifying the 149 "ATMARP Client Autoconfiguration" service is defined according to [2] 150 as follows: 152 C5.0079.xx.xxxxxx.xxxx.nnnnnnnn.???????00001.00 154 where nnnnnnnn is the 32-bit subnet number determined by the client 155 or server. 157 [Note: xx digits to be assigned by the ATM Forum] 159 5. Open Issues 161 One of the interesting issues concerning this scheme is how to manage 162 the dynamic relationship existing between a Classical IP LIS and P- 163 NNI [3] peer groups. A Classical IP LIS may overlay P-NNI peer groups 164 in an arbitrary way. When a LIS-specific anycast address is used to 165 set up a connection to the ARP server, the client must either 166 explicitly supply a Connection Scope Selection IE and choose the 167 appropriate scope for the call or use the default (Local Network) 168 provided by the network. However, how does one choose the appropriate 169 connection scope a priori? What happens when the underlying P-NNI 170 topology changes such that certain clients or servers are pushed 171 outside the scope used by other clients or servers to initially setup 172 connections to the affected stations? What happens when the 173 boundaries of the LIS change such that certain clients or servers end 174 up in P-NNI peer groups outside the scope of any existing calls setup 175 by anycast? 177 Perhaps one approach that might be used to address these issues would 178 be for the client, at initialization, to attempt to setup a call 179 using the LIS-specific anycast address and the lowest possible scope. 180 If a connection cannot be established at this scope, try the next 181 highest scope, and so on. Once a connection has been established, the 182 client should record the scope at which the connection was 183 successful. If for any reason, the client's connection would be 184 released, it could first try to re-establish the connection using the 185 scope that was previously successful. This topic requries further 186 consideration. 188 6. References 190 [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, 191 Hewlett-Packard Laboratories, January 1994. 193 [2] ATM Forum, "ATM User-Network Interface (UNI) Signalling 194 Specification Version 4.0", ATM Forum, December 1995. 196 [3] ATM Forum, "PNNI Draft Specification", 94-0471R12, 197 ATM Forum 199 7. Security Considerations 201 Security issues are not addressed in this memo. 203 8. Acknowledgments 205 The authors would like thank Drew Perkins (FORE Systems) for useful 206 feedback on earlier versions of this proposal. 208 9. Authors' Addresses 210 Carl Marcinik 211 FORE Systems, Inc. 212 Pittsburgh Office and Research Park 213 5800 Corporate Drive 214 Pittsburgh, PA 15237-5829 216 Phone: (412) 635-3338 217 EMail: carlm@fore.com 219 Fong Ching Liaw 220 Ipsilon Networks, Inc. 221 2191 E. Bayshore Road, Suite 100 222 Palo Alto, CA 94303 224 Phone: (415) 846-4600 225 EMail: fong@ipsilon.com