idnits 2.17.1 draft-ietf-atm-classic-ip-06.txt: ** The Abstract section seems to be numbered 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 65: '... o MUST, SHALL, or MANDATORY -- th...' RFC 2119 keyword, line 68: '... o SHOULD or RECOMMEND -- this ite...' RFC 2119 keyword, line 71: '... o MAY or OPTIONAL -- the item is ...' RFC 2119 keyword, line 237: '... IP subnets MUST communicate via an ...' RFC 2119 keyword, line 255: '...members of a LIS MUST have a mechanism...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 557 has weird spacing: '...qoctets sourc...' == Line 558 has weird spacing: '...roctets sourc...' == Line 559 has weird spacing: '...soctets sourc...' == Line 560 has weird spacing: '...xoctets targe...' == Line 561 has weird spacing: '...yoctets targe...' == (1 more instance...) -- 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 (December 20, 1993) is 11085 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 1483 (ref. '2') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1340 (ref. '4') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1237 (ref. '11') (Obsoleted by RFC 1629) ** Obsolete normative reference: RFC 1293 (ref. '12') (Obsoleted by RFC 2390) -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mark Laubach 3 INTERNET DRAFT Hewlett-Packard Laboratories 4 Expires June 20, 1994 December 20, 1993 5 7 Classical IP and ARP over ATM 9 Status of this Memo 11 This memo is an internet draft. Internet Drafts are working documents 12 of the Internet Engineering Task Force (IETF), its Areas, and its 13 Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress". Please check the lid-abstracts.txt 21 listing contained in the internet-drafts shadow directories on 22 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or 23 munnari.oz.au to learn the current status of any Internet Draft. 25 1. Abstract 27 This memo defines an initial application of classical IP and ARP in 28 an Asynchronous Transfer Mode (ATM) network environment configured as 29 a Logical IP Subnetwork (LIS) as described in Section 5. This memo 30 does not preclude the subsequent development of ATM technology into 31 areas other than a LIS; specifically, as single ATM networks grow to 32 replace many ethernet local LAN segments and as these networks become 33 globally connected, the application of IP and ARP will be treated 34 differently. This memo considers only the application of ATM as a 35 direct replacement for the "wires" and local LAN segments connecting 36 IP end-stations ("members") and routers operating in the "classical" 37 LAN-based paradigm. Issues raised by MAC level bridging and LAN 38 emulation are beyond the scope of this paper. 40 This memo introduces general ATM technology and nomenclature. 41 Readers are encouraged to review the ATM Forum and ITU-TS (formerly 42 CCITT) references for more detailed information about ATM 43 implementation agreements and standards. 45 DRAFT Classical IP and ARP over ATM December 1993 47 2. Acknowledgment 49 This memo could not have come into being without the critical review 50 from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and 51 Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The 52 concepts and models presented in [1], written by Dave Piscitello and 53 Joseph Lawrence, laid the structural groundwork for this work. ARP 54 [3] written by Dave Plummer and Inverse ARP [12] written by Terry 55 Bradley and Caralyn Brown are the foundation of ATMARP presented in 56 this memo. This document could have not been completed without the 57 expertise of the IP over ATM Working Group of the IETF and the ad hoc 58 PVC committee at the Amsterdam IETF meeting. 60 3. Conventions 62 The following language conventions are used in the items of 63 specification in this document: 65 o MUST, SHALL, or MANDATORY -- the item is an absolute requirement 66 of the specification. 68 o SHOULD or RECOMMEND -- this item should generally be followed for 69 all but exceptional circumstances. 71 o MAY or OPTIONAL -- the item is truly optional and may be followed 72 or ignored according to the needs of the implementor. 74 4. Introduction 76 The goal of this specification is to allow compatible and 77 interoperable implementations for transmitting IP datagrams and ATM 78 Address Resolution Protocol (ATMARP) requests and replies over ATM 79 Adaptation Layer 5 (AAL5)[2,6]. 81 Note: this memo defines only the operation of IP and address 82 resolution over ATM, and is not meant to describe the operation of 83 ATM networks. Any reference to virtual connections, permanent virtual 84 connections, or switched virtual connections applies only to virtual 85 channel connections used to support IP and address resolution over 86 ATM, and thus are assumed to be using AAL5. This memo places no 87 restrictions or requirements on virtual connections used for other 88 purposes. 90 Initial deployment of ATM provides a LAN segment replacement for: 92 1) Local area networks (e.g., Ethernets, Token Rings and FDDI). 94 2) Local-area backbones between existing (non-ATM) LANs. 96 DRAFT Classical IP and ARP over ATM December 1993 98 3) Dedicated circuits or frame relay PVCs between IP routers. 100 Note: In 1), local IP routers with one or more ATM interfaces will be 101 able to connect islands of ATM networks. In 3), public or private 102 ATM Wide Area networks will be used to connect IP routers, which in 103 turn may or may not connect to local ATM networks. ATM WANs and LANs 104 may be interconnected. 106 Private ATM networks (local or wide area) will use the private ATM 107 address structure specified in the ATM Forum UNI specification [9]. 108 This structure is modeled after the format of an OSI Network Service 109 Access Point Address. A private ATM address uniquely identifies an 110 ATM endpoint. Public networks will use either the address structure 111 specified in ITU-TS recommendation E.164 or the private network ATM 112 address structure. An E.164 address uniquely identifies an interface 113 to a public network. 115 The characteristics and features of ATM networks are different than 116 those found in LANs: 118 o ATM provides a Virtual Connection (VC) switched environment. VC 119 setup may be done on either a Permanent Virtual Connection (PVC) 120 or dynamic Switched Virtual Connection (SVC) basis. SVC call 121 management signalling is performed via implementations of the 122 Q.93B protocol [7,9]. 124 o Data to be passed by a VC is segmented into 53 octet quantities 125 called cells (5 octets of ATM header and 48 octets of data). 127 o The function of mapping user Protocol Data Units (PDUs) into the 128 information field of the ATM cell and vice versa is performed in 129 the ATM Adaptation Layer (AAL). When a VC is created a specific 130 AAL type is associated with the VC. There are four different AAL 131 types, which are referred to individually as "AAL1", "AAL2", 132 "AAL3/4", and "AAL5". (Note: this memo concerns itself with the 133 mapping of IP and ATMARP over AAL5 only. The other AAL types are 134 mentioned for introductory purposes only.) The AAL type is known 135 by the VC end points via the call setup mechanism and is not 136 carried in the ATM cell header. For PVCs the AAL type is 137 administratively configured at the end points when the Connection 138 (circuit) is set up. For SVCs, the AAL type is communicated 139 along the VC path via Q.93B as part of call setup establishment 140 and the end points use the signaled information for 141 configuration. ATM switches generally do not care about the AAL 142 type of VCs. The AAL5 format specifies a packet format with a 143 maximum size of (64K - 1) octets of user data. Cells for an AAL5 144 PDU are transmitted first to last, the last cell indicating the 145 end of the PDU. ATM standards guarantee that on a given VC, cell 147 DRAFT Classical IP and ARP over ATM December 1993 149 ordering is preserved end-to-end. NOTE: AAL5 provides a non- 150 assured data transfer service - it is up to higher-level 151 protocols to provide retransmission. 153 o ATM Forum signalling defines point-to-point and point-to- 154 multipoint Connection setup [9]. Multipoint-to-multipoint VCs 155 are not yet specified by ITU-TS or ATM Forum. 157 o An ATM Forum ATM endpoint address is either encoded as an NSAP 158 Address (NSAPA) or is an E.164 Public-UNI address [9]. In some 159 cases, both an ATM endpoint address and an E.164 Public UNI 160 address are needed by an ATMARP client to reach another host or 161 router. Since the use of ATM endpoint addresses and E.164 public 162 UNI addresses by ATMARP are analogous to the use of Ethernet 163 addresses, the notion of "hardware address" is extended to 164 encompass ATM addresses in the context of ATMARP, even though ATM 165 addresses need not have hardware significance. ATM Forum NSAPAs 166 use the same basic format as U.S. GOSIP NSAPAs [11]. Note: ATM 167 Forum addresses should not be construed as being U.S. GOSIP 168 NSAPAs. They are not, the administration is different, which 169 fields get filled out are different, etc. 171 This memo describes the initial deployment of ATM within "classical" 172 IP networks as a direct replacement for local area networks 173 (ethernets) and for IP links which interconnect routers, either 174 within or between administrative domains. The "classical" model here 175 refers to the treatment of the ATM host adapter as a networking 176 interface to the IP protocol stack operating in a LAN-based paradigm. 178 Characteristics of the classical model are: 180 o The same maximum transmission unit (MTU) size is used for all VCs 181 in a LIS [2]. (Refer to Section 7.) 183 o Default LLC/SNAP encapsulation of IP packets. 185 o End-to-end IP routing architecture stays the same. 187 o IP addresses are resolved to ATM addresses by use of an ATMARP 188 service within the LIS - ATMARPs stay within the LIS. From a 189 client's perspective, the ATMARP architecture stays faithful to 190 the basic ARP model presented in [3]. 192 o One IP subnet is used for many hosts and routers. Each VC 193 directly connects two IP members within the same LIS. 195 Future memos will describe the operation of IP over ATM when ATM 196 networks become globally deployed and interconnected. 198 DRAFT Classical IP and ARP over ATM December 1993 200 The deployment of ATM into the Internet community is just beginning 201 and will take many years to complete. During the early part of this 202 period, we expect deployment to follow traditional IP subnet 203 boundaries for the following reasons: 205 o Administrators and managers of IP subnetworks will tend to 206 initially follow the same models as they currently have deployed. 207 The mindset of the community will change slowly over time as ATM 208 increases its coverage and builds its credibility. 210 o Policy administration practices rely on the security, access, 211 routing, and filtering capability of IP Internet gateways: i.e. 212 firewalls. ATM will not be allowed to "back-door" around these 213 mechanisms until ATM provides better management capability than 214 the existing services and practices. 216 o Standards for global IP over ATM will take some time to complete 217 and deploy. 219 This memo details the treatment of the classical model of IP and 220 ATMARP over ATM. This memo does not preclude the subsequent treatment 221 of ATM networks within the IP framework as ATM becomes globally 222 deployed and interconnected; this will be the subject of future 223 documents. This memo does not address issues related to transparent 224 data link layer interoperability. 226 5. IP Subnetwork Configuration 228 In the LIS scenario, each separate administrative entity configures 229 its hosts and routers within a closed logical IP subnetwork. Each 230 LIS operates and communicates independently of other LISs on the same 231 ATM network. Hosts connected to ATM communicate directly to other 232 hosts within the same LIS. Communication to hosts outside of the 233 local LIS is provided via an IP router. This router is an ATM 234 Endpoint attached to the ATM network that is configured as a member 235 of one or more LISs. This configuration may result in a number of 236 disjoint LISs operating over the same ATM network. Hosts of differing 237 IP subnets MUST communicate via an intermediate IP router even though 238 it may be possible to open a direct VC between the two IP members 239 over the ATM network. 241 The requirements for IP members (hosts, routers) operating in an ATM 242 LIS configuration are: 244 o All members have the same IP network/subnet number and address 245 mask [8]. 247 o All members within a LIS are directly connected to the ATM 249 DRAFT Classical IP and ARP over ATM December 1993 251 network. 253 o All members outside of the LIS are accessed via a router. 255 o All members of a LIS MUST have a mechanism for resolving IP 256 addresses to ATM addresses via ATMARP (based on [3]) and vice 257 versa via InATMARP (based on [12]) when using SVCs. Refer to 258 Section 8 "Address Resolution" in this memo. 260 o All members of a LIS MUST have a mechanism for resolving VCs to 261 IP addresses via InATMARP (based on [12]) when using PVCs. Refer 262 to Section 8 "Address Resolution" in this memo. 264 o All members within a LIS MUST be able to communicate via ATM with 265 all other members in the same LIS; i.e., the virtual Connection 266 topology underlying the intercommunication among the members is 267 fully meshed. 269 The following list identifies a set of ATM specific parameters that 270 MUST be implemented in each IP station connected to the ATM network: 272 o ATM Hardware Address (atm$ha). The ATM address of the individual 273 IP station. 275 o ATMARP Request Address (atm$arp-req). atm$arp-req is the ATM 276 address of an individual ATMARP server located within the LIS. 277 In an SVC environment, ATMARP requests are sent to this address 278 for the resolution of target protocol addresses to target ATM 279 addresses. That server MUST have authoritative responsibility 280 for resolving ATMARP requests of all IP members within the LIS. 281 Note: if the LIS is operating with PVCs only, then this parameter 282 may be set to null and the IP station is not required to send 283 ATMARP requests to the ATMARP server. 285 It is RECOMMENDED that routers providing LIS functionality over the 286 ATM network also support the ability to interconnect multiple LISs. 287 Routers that wish to provide interconnection of differing LISs MUST 288 be able to support multiple sets of these parameters (one set for 289 each connected LIS) and be able to associate each set of parameters 290 to a specific IP network/ subnet number. In addition, it is 291 RECOMMENDED that a router be able to provide this multiple LIS 292 support with a single physical ATM interface that may have one or 293 more individual ATM endpoint addresses. Note: this does not 294 necessarily mean different End System Identifiers (ESIs) when NSAPAs 295 are used. The last octet of an NSAPA is the NSAPA Selector (SEL) 296 field which can be used to differentiate up to 256 different LISs for 297 the same ESI. (Refer to Section 5.1.3.1, "Private Networks" in [9].) 299 DRAFT Classical IP and ARP over ATM December 1993 301 6. Packet Format 303 Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as 304 described in [2]. LLC/SNAP encapsulation is the default packet 305 format for IP datagrams. 307 This memo recognizes that other encapsulation methods may be used 308 however, in the absence of other knowledge or agreement, LLC/SNAP 309 encapsulation is the default. 311 This memo recognizes the future deployment of end-to-end signalling 312 within ATM that will allow negotiation of encapsulation method on a 313 per-VC basis. Signalling negotiations are beyond the scope of this 314 memo. 316 7. MTU Size 318 The default MTU size for IP members operating over the ATM network 319 SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the 320 default ATM AAL5 protocol data unit size is 9188 octets [2]. In 321 classical IP subnets, values other than the default can be used if 322 and only if all members in the LIS have been configured to use the 323 non-default value. 325 This memo recognizes the future deployment of end-to-end signalling 326 within ATM that will allow negotiation of MTU size on a per-VC basis. 327 Signalling negotiations are beyond the scope of this document. 329 8. ADDRESS RESOLUTION 331 Address resolution within an ATM logical IP subnet SHALL make use of 332 the ATM Address Resolution Protocol (ATMARP) (based on [3]) and the 333 Inverse ATM Address Resolution Protocol (InATMARP) (based on [12]) as 334 defined in this memo. ATMARP is the same protocol as the ARP 335 protocol presented in [3] with extensions needed to support ARP in a 336 unicast server ATM environment. InATMARP is the same protocol as the 337 original InARP protocol presented in [12] but applied to ATM 338 networks. All IP stations MUST support these protocols as updated 339 and extended in this memo. Use of these protocols differs depending 340 on whether PVCs or SVCs are used. 342 8.1 Permanent Virtual Connections 344 An IP station MUST have a mechanism (eg. manual configuration) for 345 determining what PVCs it has, and in particular which PVCs are being 346 used with LLC/SNAP encapsulation. The details of the mechanism are 347 beyond the scope of this memo. 349 DRAFT Classical IP and ARP over ATM December 1993 351 All IP members supporting PVCs are required to use the Inverse ATM 352 Address Resolution Protocol (InATMARP) (refer to [12]) on those VCs 353 using LLC/SNAP encapsulation. In a strict PVC environment, the 354 receiver SHALL infer the relevant VC from the VC on which the 355 InATMARP request (InARP_REQUEST) or response (InARP_REPLY) was 356 received. When the ATM source and/or target address is unknown, the 357 corresponding ATM address length in the InATMARP packet MUST be set 358 to zero (0) indicating a null length, otherwise the appropriate 359 address field should be filled in and the corresponding length set 360 appropriately. InATMARP packet format details are presented later in 361 this memo. 363 Directly from [12]: "When the requesting station receives the InARP 364 reply, it may complete the [ATM]ARP table entry and use the provided 365 address information. Note: as with [ATM]ARP, information learned via 366 In[ATM]ARP may be aged or invalidated under certain circumstances." 367 It is the responsibility of each IP station supporting PVCs to re- 368 validate [ATM]ARP table entries as part of the aging process. See 369 the Section 8.5 on "ATMARP Table Aging". 371 8.2 Switched Virtual Connections 373 SVCs require support for ATMARP in the non-broadcast, non-multicast 374 environment that ATM networks currently provide. To meet this need a 375 single ATMARP Server MUST be located within the LIS. This server MUST 376 have authoritative responsibility for resolving the ATMARP requests 377 of all IP members within the LIS. 379 The server itself does not actively establish connections. It 380 depends on the clients in the LIS to initiate the ATMARP registration 381 procedure. An individual client connects to the ATMARP server using 382 a point-to-point VC. The server, upon the completion of an ATM 383 call/connection of a new VC specifying LLC/SNAP encapsulation, will 384 transmit an InATMARP request to determine the IP address of the 385 client. The InATMARP reply from the client contains the information 386 necessary for the ATMARP Server to build its ATMARP table cache. This 387 information is used to generate replies to the ATMARP requests it 388 receives. 390 The ATMARP Server mechanism requires that each client be 391 administratively configured with the ATM address of the ATMARP Server 392 atm$arp-req as defined earlier in this memo. There is to be one and 393 only one ATMARP Server operational per logical IP subnet. It is 394 RECOMMENDED that the ATMARP Server also be an IP station. This 395 station MUST be administratively configured to operate and recognize 396 itself as the ATMARP Server for a LIS. The ATMARP Server MUST be 397 configured with an IP address for each logical IP subnet it is 398 serving to support InATMARP requests. 400 DRAFT Classical IP and ARP over ATM December 1993 402 This memo recognizes that a single ATMARP Server is not as robust as 403 multiple servers which synchronize their databases correctly. This 404 document is defining the client-server interaction by using a simple, 405 single server approach as a reference model, and does not prohibit 406 more robust approaches which use the same client-server interface. 408 8.3 ATMARP Server Operational Requirements 410 The ATMARP server accepts ATM calls/connections from other ATM end 411 points. At call setup and if the VC supports LLC/SNAP encapsulation, 412 the ATMARP server will transmit to the originating ATM station an 413 InATMARP request (InARP_REQUEST) for each logical IP subnet the 414 server is configured to serve. After receiving an InATMARP reply 415 (InARP_REPLY), the server will examine the IP address and the ATM 416 address. The server will add (or update) the map entry and timestamp into its ATMARP table. If the 418 InATMARP IP address duplicates a table entry IP address and the 419 InATMARP ATM address does not match the table entry ATM address and 420 there is an open VC associated with that table entry, the InATMARP 421 information is discarded and no modifications to the table are made. 422 ATMARP table entries persist until aged or invalidated. VC call tear 423 down does not remove ATMARP table entries. 425 The ATMARP server, upon receiving an ATMARP request (ARP_REQUEST), 426 will generate the corresponding ATMARP reply (ARP_REPLY) if it has an 427 entry in its ATMARP table. Otherwise it will generate a negative 428 ATMARP reply (ARP_NAK). The ARP_NAK response is an extension to the 429 ARMARP protocol and is used to improve the robustness of the ATMARP 430 server mechanism. With ARP_NAK, a client can determine the 431 difference between a catastrophic server failure and an ATMARP table 432 lookup failure. The ARP_NAK packet format is the same as the 433 received ARP_REQUEST packet format with the operation code set to 434 ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for 435 transmission with the ARP_REQUEST operation code reset to ARP_NAK. 437 Updating the ATMARP table information timeout, the short form: when 438 the server receives an ATMARP request over a VC, where the source IP 439 and ATM address match the association already in the ATMARP table and 440 the ATM address matches that associated with the VC, the server may 441 update the timeout on the source ATMARP table entry: i.e., if the 442 client is sending ATMARP requests to the server over the same VC that 443 it used to register its ATMARP entry, the server should examine the 444 ATMARP requests and note that the client is still "alive" by updating 445 the timeout on the client's ATMARP table entry. 447 Adding robustness to the address resolution mechanism using ATMARP: 448 when the server receives an ARP_REQUEST over a VC, it examines the 449 source information. If there is no IP address associated with the VC 451 DRAFT Classical IP and ARP over ATM December 1993 453 over which the ATMARP request was received and if the source IP 454 address is not associated with any other connection, then the server 455 will add the entry and timestamp into its 456 ATMARP table and associate the entry with this VC. 458 8.4 ATMARP Client Operational Requirements 460 The ATMARP client is responsible for contacting the ATMARP server to 461 register its own ATMARP information and to gain and refresh its own 462 ATMARP entry/information about other IP members. This means, as 463 noted above, that ATMARP clients MUST be configured with the ATM 464 address of the ATMARP server. ATMARP clients MUST: 466 1. Initiate the VC connection to the ATMARP server for transmitting 467 and receiving ATMARP and InATMARP packets. 469 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any 470 VC appropriately. (Refer to Section 7, "Protocol Operation" in 471 [12].) 473 3. Generate and transmit ARP_REQUEST packets to the ATMARP server and 474 to process ARP_REPLY and ARP_NAK packets from the server 475 appropriately. ARP_REPLY packets should be used to build/refresh its 476 own client ATMARP table entries. 478 4. Generate and transmit InARP_REQUEST packets as needed and to 479 process InARP_REPLY packets appropriately. InARP_REPLY packets 480 should be used to build/refresh its own client ATMARP table entries. 481 (Refer to Section 7, "Protocol Operation" in [12].) 483 5. Provide an ATMARP table aging function to remove its own old 484 client ATMARP tables entries after a convenient period of time. 486 Note: if the client does not maintain an open VC to the server, the 487 client MUST refresh its ATMARP information with the server at least 488 once every 20 minutes. This is done by opening a VC to the server 489 and exchanging the initial InATMARP packets. 491 8.5 ATMARP Table Aging 493 An ATMARP client or server MUST have knowledge of any open VCs it has 494 (permanent or switched), their association with an ATMARP table 495 entry, and in particular, which VCs support LLC/SNAP encapsulation. 497 Client ATMARP table entries are valid for a maximum time of 15 498 minutes. 500 Server ATMARP table entries are valid for a minimum time of 20 502 DRAFT Classical IP and ARP over ATM December 1993 504 minutes. 506 Prior to aging an ATMARP table entry, an ATMARP server MUST generate 507 an InARP_REQUEST on any open VC associated with that entry. If an 508 InARP_REPLY is received, that table entry is updated and not deleted. 509 If there is no open VC associated with the table entry, the entry is 510 deleted. 512 When an ATMARP table entry ages, an ATMARP client MUST invalidate the 513 table entry. If there is no open VC associated with the invalidated 514 entry, that entry is deleted. In the case of an invalidated entry and 515 an open VC, the ATMARP client must revalidate the entry prior to 516 transmitting any non address resolution traffic on that VC. In the 517 case of a PVC, the client validates the entry by transmitting an 518 InARP_REQUEST and updating the entry on receipt of an InARP_REPLY. In 519 the case of an SVC, the client validates the entry by transmitting an 520 ARP_REQUEST to the ATMARP Server and updating the entry on receipt of 521 an ARP_REPLY. If a VC with an associated invalidated ATMARP table 522 entry is closed, that table entry is removed. 524 8.6 ATMARP and InATMARP Packet Format 526 Internet addresses are assigned independently of ATM addresses. Each 527 host implementation MUST know its own IP and ATM address(es) and MUST 528 respond to address resolution requests appropriately. IP members 529 MUST also use ATMARP and InATMARP to resolve IP addresses to ATM 530 addresses when needed. 532 The ATMARP and InATMARP protocols use the same hardware type 533 (ar$hrd), protocol type (ar$pro), and operation code (ar$op) data 534 formats as the ARP and InARP protocols [3,12]. The location of these 535 fields within the ATMARP packet are in the same byte position as 536 those in ARP and InARP packets. A unique hardware type value has 537 been assigned for ATMARP. In addition, ATMARP makes use of an 538 additional operation code for ARP_NAK. The remainder of the 539 ATMARP/InATMARP packet format is different than the ARP/InARP packet 540 format. 542 The ATMARP and InATMARP protocols have several fields that have the 543 following format and values: 545 DRAFT Classical IP and ARP over ATM December 1993 547 Data: 548 ar$hrd 16 bits Hardware type 549 ar$pro 16 bits Protocol type 550 ar$shtl 8 bits Type & length of source ATM number (q) 551 ar$sstl 8 bits Type & length of source ATM subaddress (r) 552 ar$op 16 bits Operation code (request, reply, or NAK) 553 ar$spln 8 bits Length of source protocol address (s) 554 ar$thtl 8 bits Type & length of target ATM number (x) 555 ar$tstl 8 bits Type & length of target ATM subaddress (y) 556 ar$tpln 8 bits Length of target protocol address (z) 557 ar$sha qoctets source ATM number 558 ar$ssa roctets source ATM subaddress 559 ar$spa soctets source protocol address 560 ar$tha xoctets target ATM number 561 ar$tsa yoctets target ATM subaddress 562 ar$tpa zoctets target protocol address 564 Where: 565 ar$hrd - assigned to ATM Forum address family and is 566 19 decimal (0x0013) [4]. 568 ar$pro - see Assigned Numbers for protocol type number for 569 the protocol using ATMARP. (IP is 0x0800). 571 ar$op - The operation type value (decimal): 572 ARP_REQUEST = 1 573 ARP_REPLY = 2 574 InARP_REQUEST = 8 575 InARP_REPLY = 9 576 ARP_NAK = 10 578 ar$spln - length in octets of the source protocol address. For 579 IP ar$spln is 4. 581 ar$tpln - length in octets of the target protocol address. For 582 IP ar$tpln is 4. 584 ar$sha - source ATM number (E.164 or ATM Forum NSAPA) 586 ar$ssa - source ATM subaddress (ATM Forum NSAPA) 588 ar$spa - source protocol address 590 ar$tha - target ATM number (E.164 or ATM Forum NSAPA) 592 ar$tsa - target ATM subaddress (ATM Forum NSAPA) 594 ar$tpa - target protocol address 596 DRAFT Classical IP and ARP over ATM December 1993 598 The encoding of the 8-bit type and length value for ar$shtl, 599 ar$sstl, ar$thtl, and ar$tstl is as follows: 601 MSB 8 7 6 5 4 3 2 1 LSB 602 +-----+-----+-----+-----+-----+-----+-----+-----+ 603 | 0 | 1/0 | Octet length of address | 604 +-----+-----+-----+-----+-----+-----+-----+-----+ 606 Where: 607 bit.8 (reserved) = 0 (for future use) 609 bit.7 (type) = 0 ATM Forum NSAPA format 610 = 1 E.164 format 612 bit.6-1 (length) = 6 bit unsigned octet length of address 613 (MSB = bit.6, LSB = bit.1) 615 ATM addresses in Q.93B (as defined by the ATM Forum UNI 3.0 616 signalling specification [9]) include a "Calling Party Number 617 Information Element" and a "Calling Party Subaddress Information 618 Element". These Information Elements (IEs) SHOULD map to 619 ATMARP/InATMARP source ATM number and source ATM subaddress 620 respectively. Furthermore, ATM Forum defines a "Called Party Number 621 Information Element" and a "Called Party Subaddress Information 622 Element". These IEs map to ATMARP/InATMARP target ATM number and 623 target ATM subaddress respectively. 625 The ATM Forum defines three structures for the combined use of number 626 and subaddress [9]: 628 ATM Number ATM Subaddress 629 -------------- -------------- 630 Structure 1 ATM Forum NSAPA null 631 Structure 2 E.164 null 632 Structure 3 E.164 ATM Forum NSAPA 634 IP members MUST register their ATM endpoint address with their ATMARP 635 server using the ATM address structure appropriate for their ATM 636 network connection: i.e., LISs implemented over ATM LANs following 637 ATM Forum UNI 3.0 should register using Structure 1; LISs implemented 638 over an E.164 "public" ATM network should register using Structure 2. 639 A LIS implemented over a combination of ATM LANs and public ATM 640 networks may need to register using Structure 3. Implementations 641 based on this memo MUST support all three ATM address structures. 643 ATMARP and InATMARP requests and replies for ATM address structures 1 644 and 2 MUST indicate a null ATM subaddress; i.e. ar$sstl.type = 1 and 645 ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0. When 647 DRAFT Classical IP and ARP over ATM December 1993 649 ar$sstl.length and ar$tstl.length =0, the ar$tsa and ar$ssa fields 650 are not present. 652 Note: the ATMARP packet format presented in this memo is general in 653 nature in that the ATM number and ATM subaddress fields SHOULD map 654 directly to the corresponding Q.93B fields used for ATM 655 call/connection setup signalling messages. The IP over ATM Working 656 Group expects ATM Forum NSAPA numbers (Structure 1) to predominate 657 over E.164 numbers (Structure 2) as ATM endpoint identifiers within 658 ATM LANs. The ATM Forum's VC Routing specification is not complete 659 at this time and therefore its impact on the operational use of ATM 660 Address Structure 3 is undefined. The ATM Forum will be defining this 661 relationship in the future. It is for this reason that IP members 662 need to support all three ATM address structures. 664 8.7 ATMARP/InATMARP Packet Encapsulation 666 ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using 667 LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field 668 for ATMARP/InATMARP PDUs is: 670 Payload Format for ATMARP/InATMARP PDUs: 671 +------------------------------+ 672 | LLC 0xAA-AA-03 | 673 +------------------------------+ 674 | OUI 0x00-00-00 | 675 +------------------------------+ 676 | Ethertype 0x08-06 | 677 +------------------------------+ 678 | | 679 | ATMARP/InATMARP Packet | 680 | | 681 +------------------------------+ 683 The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a 684 SNAP header. 686 The OUI value of 0x00-00-00 (3 octets) indicates that the following 687 two-bytes is an ethertype. 689 The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. 691 The total size of the LLC/SNAP header is fixed at 8-octets. This 692 aligns the start of the ATMARP packet on a 64-bit boundary relative 693 to the start of the AAL5 CPCS-SDU. 695 The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is 696 consistent with the treatment of multiprotocol encapsulation of IP 698 DRAFT Classical IP and ARP over ATM December 1993 700 over ATM AAL5 as specified in [2] and in the format of ATMARP over 701 IEEE 802 networks as specified in [5]. 703 Traditionally, address resolution requests are broadcast to all 704 directly connected IP members within a LIS. It is conceivable in the 705 future that larger scaled ATM networks may handle ATMARP requests to 706 destinations outside the originating LIS, perhaps even globally; 707 issues raised by ATMARP'ing outside the LIS or by a global ATMARP 708 mechanism are beyond the scope of this memo. 710 9. IP Broadcast Address 712 ATM does not support broadcast addressing, therefore there are no 713 mappings available from IP broadcast addresses to ATM broadcast 714 services. Note: this lack of mapping does not restrict members from 715 transmitting or receiving IP datagrams specifying any of the four 716 standard IP broadcast address forms as described in [8]. Members, 717 upon receiving an IP broadcast or IP subnet broadcast for their LIS, 718 MUST process the packet as if addressed to that station. 720 10. IP Multicast Address 722 ATM does not support multicast address services, therefore there are 723 no mappings available from IP multicast addresses to ATM multicast 724 services. Current IP multicast implementations (i.e., MBONE and IP 725 tunneling, see [10]) will continue to operate over ATM based logical 726 IP subnets if operated in the WAN configuration. 728 This memo recognizes the future development of ATM multicast service 729 addressing by the ATM Forum. When available and widely implemented, 730 the roll-over from the current IP multicast architecture to this new 731 ATM architecture will be straightforward. 733 11. Security 735 Not all of the security issues relating to IP over ATM are clearly 736 understood at this time, due to the fluid state of ATM 737 specifications, newness of the technology, and other factors. 739 It is believed that ATM and IP facilities for authenticated call 740 management, authenticated end-to-end communications, and data 741 encryption will be needed in globally connected ATM networks. Such 742 future security facilities and their use by IP networks are beyond 743 the scope of this memo. 745 There are known security issues relating to host impersonation via 746 the address resolution protocols used in the Internet [13]. No 747 special security mechanisms have been added to the address resolution 749 DRAFT Classical IP and ARP over ATM December 1993 751 mechanism defined here for use with networks using IP over ATM. 753 12. Open Issues 755 o Interim Local Management Interface (ILMI) services will not be 756 generally implemented initially by some providers and vendors and 757 will not be used to obtain the ATM address network prefix from 758 the network [9]. Meta-signalling does provide some of this 759 functionality and in the future we need to document the options. 761 o Well known ATM address(es) for ATMARP servers? It would be very 762 handy if a mechanism were available for determining the "well 763 known" ATM address(es) for the client's ATMARP server in the LIS. 765 o There are many VC management issues which have not yet been 766 addressed by this specification and which await the unwary 767 implementor. For example, one problem that has not yet been 768 resolved is how two IP members decide which of duplicate VCs can 769 be released without causing VC thrashing. If two IP stations 770 simultaneously established VCs to each other, it is tempting to 771 allow only one of these VCs to be established, or to release one 772 of these VCs immediately after it is established. If both IP 773 stations simultaneously decide to release opposite VCs, a 774 thrashing effect can be created where VCs are repeatedly 775 established and immediately released. For the time being, the 776 safest strategy is to allow duplicate VCs to be established and 777 simply age them like any other VCs. 779 REFERENCES 781 [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS 782 Service", RFC1209, USC/Information Sciences Institute, March 783 1991. 785 [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation 786 Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. 788 [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - 789 Converting Network Addresses to 48.bit Ethernet Address for 790 Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. 792 [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ 793 Information Sciences Institute, July 1992. 795 [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of 796 IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information 797 Sciences Institute, February 1988. 799 DRAFT Classical IP and ARP over ATM December 1993 801 [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, 802 Geneva, 19-29 January 1993. 804 [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September 805 - 2 October 1992. 807 [8] Braden, R., "Requirements for Internet Hosts -- Communication 808 Layers", RFC1122, USC/Information Sciences Institute, October 809 1989. 811 [9] ATM Forum, "ATM User-Network Interface Specification Version 812 3.0.", ATM Forum, 480 San Antonio Road, Suite 100, Mountain View, 813 CA 94040, June 1993. 815 [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, 816 USC/Information Sciences Institute, August 1989. 818 [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, 819 "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, 820 USC/Information Sciences Institute, July 1991. 822 [12] Bradely, T., and Brown, C., "Inverse Address Resolution 823 Protocol", RFC1293, USC/Information Sciences Institute, January 824 1992. 826 [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol 827 Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 828 32-48, 1989. 830 Author's Address 832 Mark Laubach 833 Hewlett-Packard Laboratories 834 1501 Page Mill Road 835 Palo Alto, CA 94304 837 Phone: 415.857.3513 838 FAX: 415.857.8526 839 EMail: laubach@hpl.hp.com