idnits 2.17.1 draft-ietf-ion-transition-03.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-19) 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 -- 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 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 1998) is 9440 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) -- No information found for draft-ietf-ion-classic2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-10 == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-01 -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-01) exists of draft-ietf-ion-scsp-atmarp-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-nhrp-00 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internetworking Over NBMA Working Group James V. Luciani 3 INTERNET-DRAFT (Bay Networks) 4 Expires June 1998 6 Classical IP to NHRP Transition 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Abstract 28 This document describes methods and procedures for the graceful 29 transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over 30 ATM. 32 1. Introduction 34 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 35 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 36 document, are to be interpreted as described in [7]. 38 ATMARP defines an initial application of classical IP and ARP in an 39 ATM network environment configured as a LIS[1]. ATMARP only 40 considers application of ATM as a direct replacement for the "wires" 41 and local LAN segments connecting IP end-stations and routers 42 operating in the "classical" LAN-based paradigm. 44 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 45 (a host or router), wishing to communicate over a Non-Broadcast, 46 Multi-Access (NBMA) subnetwork, to determine the internetworking 47 layer addresses and NBMA addresses of suitable "NBMA next hops" 48 toward a destination station. If the destination is connected to the 49 NBMA subnetwork and direct communication is administratively allowed, 50 then the NBMA next hop is the destination station itself. Otherwise, 51 the NBMA next hop is the egress router from the NBMA subnetwork that 52 is "nearest" to the destination station. For the purposes of this 53 document, the NBMA network is of type ATM. 55 It is reasonable to expect that ATMARP Clients and NHRP Clients will 56 initially coexist within a LIS. Thus, it is necessary to define a 57 graceful transition, including a period of coexistance, from the use 58 of ATMARP to the use of NHRP for address resolution in the LIS 59 [1][2]. In short, NHSs will be required to respond to ATMARP Client 60 queries in a fashion which will permit continued use of the ATMARP 61 Client within the LIS during the ATMARP to NHRP transition period. 62 Note that this document places no protocol requirements upon 63 ATMARP[1] servers. 65 For the following, it will be assumed that the reader is familiar 66 with the terminology as described in [1][2][3]. 68 2. Service Requirements 70 If NHRP is to be used in a LIS then only NHSs will be used in the 71 LIS; that is, there will not be a mixture of NHSs and ATMARP servers 72 within the same LIS. Since ATMARP servers will not be able to 73 understand NHCs and since, as described below, NHSs will respond to 74 ATMARP Clients, this is a reasonable simplifying restriction. 76 This document will only address SVC based environments and will not 77 address PVC environments. This document will refer only to ATM AAL5 78 as the NBMA and IP as the protocol layer since ATMARP only addresses 79 these protocols. 81 2.1 NHRP Server Requirements 83 If NHRP Servers (NHS) are to be deployed in a LIS which contains both 84 ATMARP Clients and NHRP Clients then NHSs MUST respond to 85 ATMARP_Requests sent by ATMARP Clients in the same fashion that an 86 ATMARP Server would respond as described in [1]. To do this, the NHS 87 MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA- 88 AA-03, OUI=0x00-00-00, and ethertype=0x08-06. Further, the NHS MUST 89 recognize the packet formats described in Section 8.7 of [1]. 90 However, since this document does not extend to PVC environments, 91 NHSs MUST only receive/respond to values of ar$op of 1,2,10 92 (Decimal). If an NHS receives an ATMARP message with ar$op values 93 other than those previously noted then the NHS MUST discard the 94 packet and MUST NOT take any further action. 96 When an NHS receives a valid (as defined in the previous paragraph) 97 ATMARP_Request packet, the NHS MUST follow the rules described in 98 Section 8.4 of [1] with the following additional processing: 100 1) When an ATMARP_Request causes a new table entry in the NHS for 101 an ATMARP Client, that table entry MUST be marked as being of 102 type "ATMARP" so that it can be differentiated from an NHRP 103 sourced entry. 105 2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if 106 that ATMARP_Request contains an off-LIS protocol address. This 107 should never happen because the IP stack on the requesting machine 108 should automatically send the packet to the default router. If 109 this does occur then the ATMARP_Request MUST cause an ATMARP_NAK 110 to be sent to the originator. 112 In [1], an ATMARP_Request packet also serves as a 113 registraion/registration-update packet which would cause a server to 114 add an entry to a server's cache or to update a previously existing 115 entry. When an NHS receives an ATMARP_Request which causes the 116 creation of a new cache entry in the NHS or updates an existing entry 117 then that cache entry will have a holding time of 20 minutes (this is 118 the default value in [1]). 120 An NHS receiving an NHRP Resolution Request MUST NOT send a positive 121 NHRP Resolution Reply for a station which registered via ATMARP if 122 the station sending the NHRP Resolution Request is outside the LIS of 123 the station which registered itself via ATMARP. This is because the 124 station which registered via ATMARP is almost certainly not prepared 125 to accept a cut-through. When this occurs, the replying NHS must 126 send NHRP Resolution Reply which contains a CIE code of "4 - 127 Administratively Prohibited" as described in [2]. This type of reply 128 does not preclude the station sending the NHRP Resolution Request 129 from sending its data packets along the routed path but it does 130 preclude that station from setting up a cut-through VC. 132 2.2 Multi-server environments 134 Since ATMARP and NHRP work in a multi-server environment on a per LIS 135 basis, it is necessary to know how cache synchronization occurs. 136 These rules may be found in [5] and [6]. 138 3. Security Considerations 140 Not all of the security issues relating to IP over ATM are clearly 141 understood at this time, due to the fluid state of ATM 142 specifications, newness of the technology, and other factors. 144 It is believed that ATM and IP facilities for authenticated call 145 management, authenticated end-to-end communications, and data 146 encryption will be needed in globally connected ATM networks. Such 147 future security facilities and their use by IP networks are beyond 148 the scope of this memo. 150 There are known security issues relating to host impersonation via 151 the address resolution protocols used in the Internet [4]. No 152 special security mechanisms have been added to ATMARP. While NHRP 153 supplies some mechanisms for authentication, ATMARP does not. Since 154 any security mechanism is only as good as its weakest link, it should 155 be assumed that when NHRP and ATMARP exist with a given LIS, the 156 security of a combination is only as good as that supplied by ATMARP. 158 References 160 [1] Classical IP and ARP over ATM, Laubach, Halpern, 161 draft-ietf-ion-classic2-00.txt 163 [2] NBMA Next Hop Resolution Protocol (NHRP), Luciani, Katz, Piscitello, 164 Cole, draft-ietf-rolc-nhrp-10.txt. 166 [3] Server Cache Synchronization Protocol (SCSP) - NBMA, 167 J. Luciani, G. Armitage, J. Halpern, draft-ietf-ion-scsp-01.txt. 169 [4] Security Problems in the TCP/IP Protocol Suite, Bellovin, 170 ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 171 1989. 173 [5] A Distributed ATMARP Service Using SCSP, Luciani, Fox, 174 draft-ietf-ion-scsp-atmarp-00.txt 176 [6] A Distributed NHRP Service Using SCSP, Luciani, 177 draft-ietf-ion-scsp-nhrp-00.txt 179 [7] "Key words for use in RFCs to Indicate Requirement Levels", 180 S. Bradner, RFC 2119. 182 Acknowledgments 184 Thanks to Andy Malis for his input on this draft. 186 Author's Addresses 188 James V. Luciani 189 Bay Networks 190 3 Federal Street 191 Mail Stop: BL3-03 192 Billerica, MA 01821 193 Phone: +1 978 916 4734 194 Email: luciani@baynetworks.com